Occasionally when developing software you come across really absurd or bizarre bugs. The user interface for the application I’m currently developing recently exhibited one of these: a propensity for beeping periodically, for no readily explicable reason. To be precise, not so much a beeping as a “ding”ing.

Now like most software developers, I work in an environment where workstations don’t tend to have speakers. People who do want to listen to music bring in headphones, and thus get to live in their own audio universes.

So it was only whilst idly listening to some music whilst testing the latest shiny new feature that I suddenly noticed that my otherwise quite pleasantly heavy soundtrack was periodically letting up from its relentless drumming and so forth in order to go “ding”.

I’ve had this with MP3s before, usually after having employed rather low quality CD ripping software (by which I don’t necessarily mean software that isn’t commonly (mis)used for that little job on many thousands of PCs around the world). But I’d played these particular MP3s many times before without unnecessary “ding”age. They were tastefully “ding” free. Distressingly, I noticed that the “dings” corresponded quite closely with my mouse activity clicking bits of our application. The evidence was beginning to pile up.

I knew for a fact that I wasn’t advertently causing anything to go “ding” in our user interface code. So I promptly took the dutiful approach that any professional programmer would take. After careful consideration I filed a bug report, assigned it to myself, and cheerfully moved onto shinier and easier ground.

However, since we’ve been getting close to showing off this application to the public, I’ve had to return to the land of “ding”, grumbling and rolling up my sleeves.

I won’t bore you with tales of endlessly commenting out bits of user interface code, rerunning the application, toying with it, hearing it go “ding”, returning to my development environment (which also has a vexing habit of “ding”ing at me – and, mark you, a less soothing “ding” under the Windows default sound scheme than one exhibited by our application), rinse, repeat.

The upshot of this worthy investigation was that the offending “ding”s were being produced by a rich text box control. As and when we had occasion to ask it to not display anything at all, if it didn’t mind, it would “ding”. Under .NET, RichTextBox.AppendText (or more precisely, the SelectionText property invoked by AppendText) will “ding” if it’s assigned an empty string. Which is exceedingly nice of it.

This “feature” does beg one question: why? It smacks of the kind of debug code one might leave in as a control author (“hmm, might be getting empty strings, better ding to make sure people are aware of it”. But in .NET we have Exceptions for that sort of thing. There is a reason why our language doesn’t natively permit the following:

try
{
    DoSomething();
}
catch ( Exception )
{
    ding;
}

Because it would be extraordinarily and vexingly pointless, not to mention pointlessly vexing. If I did write that sort of code, I’d expect the compiler to go “ding” when I tried to compile it, at the very least.

So I recall why, when setting up a new PC, the first thing I do is turn the system sound scheme to “quiet as the grave”: the world is full of annoying applications that go “ding” at the slightest provocation. I’m happy to say that our shiny new application is no longer one of them.